The present invention is generally directed to enhancing the performance of a computing device when multiple layers are mounted to the computing device. A layering system is a tool that enables an operating system, user applications, and user data to be layered on the user's computing device. When using a layering system, layered applications and data are executed natively on the user's computing device without the use of a virtual machine or other sandboxed execution environment. This native execution will therefore cause the layered applications to appear, both to the user and to other applications, as if they were being executed in a “normal” manner. This is in contrast to many types of virtualization techniques such as terminal services and application virtualization where it is typically clear that the applications are executed in a separate environment.
U.S. patent application Ser. Nos. 14/719,248 and 14/719,256 are both directed to a layering system and provide a background for the present invention. The content of these applications is therefore incorporated by reference. It is noted that both of these applications are commonly owned and would not constitute prior art to the present invention. Therefore, this background should not be construed as admitting prior art, but should be construed as describing various features on which the present invention is based and that may even form part of the present invention.
As is described in the '248 and '256 applications, a layer is a collection of data or resources which enables the collection to be isolated or set apart from the data or resources in another layer. To summarize this layering, FIG. 1 provides simplified examples of a user data layer 101 and an application layer 102. It is noted that a layer containing an operating system may also exist. Each layer can be stored in a manner that allows the layer to be separately mounted for access. For example, each layer may comprise a separate partition of a disk (including of a virtual disk), a folder, a network share, etc. The ability to separately mount a layer allows the layering system to selectively provide access to particular layers. It will be assumed that the layering system determines that user data layer 101 and application layer 102 should be mounted in response to the user logging in to a computing device on which the layering system executes or which the layering system otherwise controls.
As shown in FIG. 1 and for simplicity, application layer 102 includes a single application, WINWORD.EXE, which is the executable for Microsoft Word. Word also requires a number of registry settings to execute properly, and therefore, application layer 102 also includes such registry settings. It is noted that these registry settings, which would normally be stored within the registry of the operating system, could be stored within application layer 102 in a registry hive. Of course, a typical installation of Word would require a number of other files and/or settings which are not depicted. Application layer 102 also includes layer metadata which describes the content of application layer 102 (e.g., which describes that the layer includes WINWORD.EXE and whatever structure is used to store the Word registry settings). This layer metadata is critical because it allows the layering system to quickly determine what exists on the layer.
User data layer 101 is structured in a similar way. However, as a user data layer, it stores the user's files which in this case constitute two Word documents: Report.docx and Summary.docx. As with application layer 102, user data layer 101 may also store a number of other files including configuration files that may be particular to this user (e.g., a template file for Word). User data layer 101 also includes layer metadata which defines the content of the layer. Again, this layer metadata is critical because it allows the layering system to quickly determine what exists on the layer.
As mentioned above, a layer can be a separately mountable portion of a storage device (whether physical or virtual) such as a partition, folder, network share, etc. Accordingly, when the user logs on to a computing device, the layering system can mount layers 101 and 102 so that the user will have access to MS Word and his documents which are included in these layers. However, if a different user were to log in to the same computing device, the layering system could instead mount an application layer and user data layer pertaining to the different user so that the different user can only access the applications and user data defined in those layers.
The process by which the user accesses the data and resources included on each layer is provided in the '248 and '256 applications and will not be described in detail in this specification. By way of an overview, the layering system includes a file system filter driver and a registry filter driver which can function to intercept and redirect file system and registry operations as appropriate. In particular, these filters can be registered with the OS so that they will receive all file system and registry operations respectively. If a file system or registry operation pertains to content of a layer rather than to content of the file system or registry directly provided by the OS, the filters can redirect the operation to the corresponding layer. The '248 and '256 applications provide a number of examples of this type of redirection.
The result of this redirection is that, from the user perspective, the files of the layers do not appear to be stored in a different manner than any other file would typically be stored by the OS. For example, if the user data layer 101 were assigned a volume of E:, the layering system could cause the files to appear as if they were stored in the typical C: volume. In other words, the fact that multiple volumes may be loaded is abstracted (and even hidden) from the user perspective. It is again reiterated that the use of layer metadata to define what is stored on each layer allows this process to be carried out efficiently as is described in the '248 and '256 applications.
FIGS. 2A and 2B each illustrate an example of how the layering system can function. Each of these examples involve the layering file system filter driver (or LFFD) 201 and its role in determining whether to redirect a file open request. It is noted that a similar process would be carried out by the layering registry filter driver (or LRFD) if the operation pertained to the registry.
As shown in FIGS. 2A and 2B, it will be assumed that the operating system provides a file system 200 for handling I/O to the various mounted partitions. It will also be assumed that the operating system has mounted a C: volume and that the layering system has mounted an E: volume that corresponds to user data layer 101. In the following description, the E: volume and user data layer 101 (or simply layer) will be used interchangeably. Because of the layering system, even though the E: volume is a separate volume from the C: volume, the contents of the E: volume will appear as if they were stored on the C: volume. In other words, the layering system can make it appear as if a single volume were mounted.
Accordingly, if the user selects to open the Report.docx file that is stored on the E: volume, a file open request 210 of C:\Docs\Report.docx may be generated. As is described in the '248 and '256 applications, LFFD 201 is registered as a filter driver for file system 200 and therefore will receive the opportunity to evaluate file open request 210. LFFD 201 can evaluate the target of file open request 210 against the layer metadata of the E: volume (and possibly against layer metadata of any other mounted layer) to determine if the request pertains to the layer. In this case, it will be assumed that the layer metadata indicates that the E: volume includes the path \Docs and that the Report.docx file is stored in the path. As a result, LFFD 201 can modify file open request 210 to create modified file open request 210a of E:\Docs\Report.docx. Modified file open request 210a is then passed to file system 200 which will open Report.docx from the appropriate location on the E: volume. LFFD 201 can perform this type of rerouting for any I/O that pertains to content stored on the E: volume. The determination of whether I/O pertains to content on a particular layer is based on the layer metadata for that particular layer.
FIG. 2B illustrates the case where LFFD 201 determines that a file open request 220 does not pertain to a layer (or at least does not pertain to a layer separate from the layer that includes the operating system). In this example, file open request 220 is directed to File.txt which is stored in a Downloads folder that is assumed to exist on the C: volume. Upon receiving file open request 220, LFFD 201 will evaluate the request against the layer metadata for the E: volume and determine that the E: volume does not include a path of \Downloads. Accordingly, LFFD 201 can allow file open request 220 to pass to file system 200 without modification since the request already includes the correct path to File.txt.
To summarize, LFFD 201 selectively modifies I/O requests so that they are directed to the appropriate layer. In the case of registry access, the LRFD would perform similar functionality to ensure that the registry access is directed to the appropriate layer. It is again reiterated that this rerouting is necessary because the layering system causes the layers to be hidden from the user's perspective while still being visible to the underlying file system.
In typical systems that implement this type of layering, there may be multiple layers mounted that each provide applications to the user. FIG. 3 illustrates an example of this. As shown, a system may include an operating system partition 301 (which may or may not be a layer) on which the operating system 302 and registry hive 303 are stored. Registry hive 303 can include configuration settings of operating system 302 and possibly of any application on operating system partition 301 or any application that may be executed on the system. As an example, operating system partition 301 can represent a typical partition of a system's hard drive or may represent a vdisk. When operating system 302 executes, it will load registry hive 303 into the registry where the configuration settings can be accessed (e.g., via the configuration manager) by the operating system and other processes/threads.
FIG. 3 also illustrates two application layers 311, 321 that are assumed to have been mounted by layering file system filter driver (LFFD) 330 on the system. As an example, each of application layers 311, 321 could be a separate drive, a separate partition of a drive, a VHD, a network share, a mounted folder, etc. Application layer 311 includes applications 312a and 312b while application layer 321 includes applications 322a and 322b. Application layers 311 and 321 also include registry hives 313 and 323 respectively which store the configuration settings for the applications on the respective application layer. For example, registry hive 313 can store any registry keys and corresponding values employed by application 312a or application 312b while registry hive 323 can store any registry keys and corresponding values employed by application 322a or application 322b. Although not shown, each application layer 311, 321 can include layer metadata (of which registry hives 313, 323 form a part).
As described in the '248 and the '256 applications, when a layer is mounted, LFFD 330 can load the layer's registry hive into the registry where it can be accessed using typical registry operations. Layering registry filter driver (LRFD) 340 can be registered with the configuration manager of operating system 302 to receive any calls to access the registry. When LRFD 340 receives a registry operation it can access the layer metadata of each layer to determine to which registry hive the registry operation should be directed. LRFD 340 can then modify the registry operation so that it includes the correct path.
FIGS. 3A-3C illustrate an example of how each of registry hives 303, 313, and 323 can be loaded into the registry. In FIG. 3A, the operating system's registry hive 303 is shown as being loaded. For simplicity, registry hive 303 is shown as including a subkey (\SOFTWARE\Microsoft\Windows\CurrentVersion) that has a single value (CommonFilesDir) with data of C:\Program Files\Common Files. When this subkey is loaded into registry 450, it will be positioned under the HKLM key as shown. Therefore, any request to access the CommonFilesDir value will specify a path of (or more particularly, will provide a handle to) HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion.
FIG. 3B illustrates how registry hive 313 can be loaded into registry 450 when application layer 311 is mounted. Registry hive 313 is shown as including a subkey (\SOFTWARE\Vendor1\Key1) that has a single value (InstallDirectory) with data of C:\Program Files\Vendor1\Dir1. Although this subkey may have a similar path as the CommonFilesDir subkey (i.e., although this subkey falls under the SOFTWARE subkey), because it is part of a different registry hive, it will be loaded in a unique location. As shown, rather than storing the \SOFTWARE\Vendor1\Key1 subkey under the existing SOFTWARE subkey (which would typically be the case if the corresponding application had been installed on operating system partition 301), the subkey is stored under the subkey AppLayer311. Accordingly, but for LRFD 340, any request to access the InstallDirectory value would need to specify a path of HKLM\AppLayer311\SOFTWARE\Vendor1\Key1. However, as described in the '248 and the '256 applications, LRFD 340 can cause the contents of registry hive 313 to appear as if it were not separate from registry hive 303. In other words, LRFD 340 can cause the value to appear as if it is located at HKLM\SOFTWARE\Vendor1\Key1.
FIG. 3C illustrates how registry hive 323 can be loaded into registry 450 when application layer 321 is mounted. The same process can be performed as described above so that subkey \SOFTWARE\Vendor2\Key1 is stored under the AppLayer321 subkey. Therefore, the EnableUsageStats value can be accessed at the path HKLM\AppLayer321\SOFTWARE\Vendor2\Key1. However, due to the role of LRFD 340, this subkey will appear to applications and the operating system as if it was stored at HKLM\SOFTWARE\Vendor2\Key1.
To implement this abstraction, LRFD 340 intercepts any registry operation to determine whether the operation is directed to a registry hive of one of the mounted layers rather than to the operating system's registry hive. For example, in response to receiving a request to obtain a value of a particular registry subkey, LRFD 340 may be configured to first access registry hive 313 to determine if it includes the key (e.g., by determining whether the subkey is stored under the AppLayer311 subkey). If the subkey is found in registry hive 313, LRFD 340 may respond with its value. However, if the subkey is not found in registry hive 313, LRFD 340 may then access registry hive 323 to perform the same process. If LRFD 340 does not find the subkey in registry hive 323, it would then allow the operating system to fulfill the request in a normal fashion.
Accordingly, LRFD 340 is configured to iteratively access the application layer registry hives when handling a registry operation. If none of the application layer registry hives have the subkey that is the target of the registry operation, LRFD 340 will pass the registry operation on to operating system 302 for normal processing.
This iterative process can degrade the performance of a layering system. For example, in practice, most registry operations will be directed to operating system registry hive 303. In such cases, LRFD 340 will still access the registry hive of each application layer prior to passing the registry operation on to the operating system. These unnecessary accesses to the application layer registry hives can significantly increase the amount of processing performed by the layering system. For example, if ten layers are mounted and a request to read a value in registry hive 303 is received, LRFD 340 may perform at least ten unnecessary mappings/reads of the registry (at least one for each application layer registry hive loaded in the registry) prior to passing the request on to the operating system.